Since the default config obtains an autodiscover config, the real config loading runs into issues more often than expected. We should remove the constriction so exclusive named config users can use the receiver.

Am I understanding correctly that autodiscover is never nil, because it is the default? Therefore, is was impossible to use named groups because validation of the config checks that only one mode is used?

Since the default config obtains an autodiscover config, the real config loading runs into issues more often than expected. We should remove the constriction so exclusive named config users can use the receiver.

Am I understanding correctly that autodiscover is never nil, because it is the default? Therefore, is was impossible to use named groups because validation of the config checks that only one mode is used?

Yes that is my understanding!

I tried to think of other ways to solve this but this felt like the simplest. If there is a preferred way, I'm open to it!

Ok, as proposed the config ends up in an ambiguous state where both autodiscover and named are set.

The correct way to handle this is to implement a custom unmarshal function for the config. Basically, we can check if autodiscover was actually set, and if not, nil out the corresponding struct.

It should look pretty much like this (adapted from fileexporter):

// Unmarshal a confmap.Conf into the config struct.
func (cfg *Config) Unmarshal(componentParser *confmap.Conf) error {
	if componentParser == nil {
		return errors.New("empty config for file exporter")
	}
	// first load the config normally
	err := componentParser.Unmarshal(cfg, confmap.WithErrorUnused())
	if err != nil {
		return err
	}
	// check if user actually specified autodiscover, or if just autoinitialized
	if !componentParser.IsSet("autodiscover") {
		cfg.Autodiscover = nil
	}
	return nil
}

@djaglowski that seemed to be a great solution, added a couple more tests to validate that these changes are safe and resolve the issue

/easycla